\section{Bus Protocol}
\label{sec:bus}

Generally our goal is to implement an easy to use bus protocol for fault tolerant application which can detect bit errors on a very low level and possibly provide forward error correction.
The physical layer of our protocol is a one wire bus accessed via an usart, which provides an dominant high and an recessive low level.
In the following we differentiate between

\begin{enumerate}
 \item the basic accessing part 
 \item the fault tolerant non starvation handling (FTNSH) part
 \item the fault tolerant non babbling idiot (FTNBI) part
\end{enumerate}

of the bus.\\

\label{figure:bus:basicaccess:statemachine}


\subsection{basic access}
\label{sec:bus:basicaccess}

The access to the bus is provided by arbitration via the Frame ID consisting of the Message Type (or Message ID), the Receivers Node ID  and the Sender Node ID, whereat the Node ID have to be globally unique among all Nodes sharing the bus.\\
Since we use the USART with a 9 bit data width but transfer 8 bits of payload a time only we can use the msb of the transferred character data for message synchronisation. A logic 1 prefixing a byte of data notifies the receiving nodes of the start of a frame.
After the synchronisation bit the arbitration mask described above followed by the payload length in byte the payload and the 32-bit-CRC checksum are transmitted. (see section \ref{sec:bus:messageformat}\\

Depicting the state machine shown in figure \ref{figure:bus:basicaccess:statemachine} we outline three cases.

\begin{enumerate}
 \item Only one node wants to transmit data and the bus is free: The node A knows that the bus is free by observing the bus since startup. A starts to write the MessageID prefixed by the synchronisation bit to the bus and listens bitwise for the data last written.
       If the bit received equals the bit written A knows the bus currently is dominated by it and the arbitration can continue. After arbitrating the whole FrameID every Node currently connected to the bus is in the RECEIVE\_STATE except A which is in the TRANSMIT\_SATE of the state machine.
       A can now send the rest of the message without being interrupted by another node.

 \item more than one node wants to transmit data: Both nodes A and B start to send the synchronisation bit and some bits of their Frame ID. Since the Node IDs have to be unique one of the two nodes does not read back the bit written on the bus and changes to the RECEIVE\_STATE. The further scenario is like the one described above.

 \item one node wants to transmit data during another node's already transmitting: Since all nodes connected to the bus are in the RECEIVE\_STATE while another node is sending the node has to wait until the other node currently sending has finished.

 \item some new node (e.g. a node just powered on): The node C just powered on has a wrong state within the protocols state machine. This means he does not know if there is a communication going on at the moment, leading to the fact of not being capable to decide when he is allowed to arbitrate the bus without violating another transmission.
       In this case C has to wait until the next synchronisation bit set HIGH is received. From this time on C has the correct state in the protocols state machine. And after receiving the current message C can start to arbitrate the bus like in one of the scenarios depicted above.
\end{enumerate}

\subsection{fault tolerant none starvation handling (FTNSH)}
\label{sec:bus:ftnsh}

Since the whole network starves in case of a fault, e.g. a hang up or a power off, at the sending node during transmission as well as on power on of the very first node, we have to provide the so called FTNSH, to ensure proper operation after some time.
For this purpose we introduce a Fault tolerant layer optional to the basic bus access handling such cases. The FTNSH handling routine is called after each receipt and sets a timer or watchdog for the time interval allowed till the next receipt.
In case the message has been transmitted correctly the timer or watchdog can be deactivated.
In case the sender node stucks during message transmission the timer or watchdog triggers an interrupt resetting the state in the protocols state machine which offers the receiver nodes to initiate a new transmission.
Another advantage of the FTNSH is a faster integration of new nodes, since a new node does not have to wait for the synchronisation bit of another message to synchronize to the bus protocol because he can set its timer or watchdog and initiate a new transmission after the configured timeout.

\subsection {fault tolerant none babbling idiot (FTNBI)}
\label{sec:bus:ftnbi}

\textit{Note: the FTNBI is not part of the protocol implementation}\\

After providing fault tolerance upon the bus protocol like outlined in the sections \ref{sec:bus:basicaccess} and \ref{sec:bus:ftnsh} we want to cover fault tolerance in case of babbling idiots at the FTNBI, by providing a simple bus guardian allowing access to the bus only at predefined times.
In case we use a FTNBI window of 20ms, the bus guardian of a node blocks the active (send) bus access for 20ms after each message sent by the node. The passive access (receive) to the bus is permitted the whole time. An additional majority voting or some other handling to detect babbling idiots can in our current design only be established with additional hard- and software implementations.


\subsection{message format in a nutshell}
\label{sec:bus:messageformat}

\begin{figure}[htbp]
  \centering
  \begin{bytefield}{24}
    \bitheader{0,3-4,9-10,15-16,23} \\

%   begin{rightwordgroup}{RTP \\ Header}
    \bitbox{4}{MsgType} & \bitbox{6}{Receiver NodeID} & \bitbox{6}{Sender NodeID}
    & \bitbox{8}{Data Len} \\
%   \end{rightwordgroup} \\

%     \wordbox[lrt]{1}{Data 0} \\
%     \skippedwords \\
% %     \wordbox[lrb]{1}{} \\
%     \wordbox[lrb]{1}{Data \textless len\textgreater}\\
    
    \bitbox{8}{Data 0} & \bitbox{8}{Data ... } & 
    \bitbox{8}{Data \textless len\textgreater}\\
    \bitbox{8}{CRC0} & \bitbox{8}{CRC ...} & \bitbox{8}{CRC 4}
  \end{bytefield}
  \caption{ULFTRT-Protocol}
  \label{figure:bus:messageformat}
\end{figure}

As shown in figure \ref{figure:bus:messageformat} the message consists of

\begin{enumerate}
 \item Message Type 
 \item Receiver Node ID
 \item Sender Node ID
 \item Data Length
 \item Data[0..N]
 \item CRC
\end{enumerate}

The \textit{MessageType}, \textit{ReceiverNodeID} and \textit{SenderNodeID} are part of the so called FrameID uniquely identifying all messages transferred on the bus.
The Field DataLength holds the length of the Payload following in bytes. The message is concluded by the 4-Byte long CRC-checksum.

\subsection{Fault Hypothesis}

... gives the applied fault hypothesis and planned countermeasures.

% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% Ein Frame setzt sich aus folgendem Inhalt zusammen
% \begin{itemize}
%   \item Frame-ID
%   \item Msg Len
%   \item Data
%   \item Checksum
% \end{itemize}
% 
% Frame-ID und Msg-Len bilden den Header jeder Nachricht.
% \\
% Die Frame-ID setzt sich aus der Message-ID und einer dem Knoten fix zugewiesenen Node-ID zusammen.
% Die Aufteilung der Bits zwischen Message- und Node-ID wird nicht spezifiziert und wird je nach Projekt verschieden aufgeteilt.\\
% \\
% Somit ist es möglich verschiedene Messagetypen von beliebig vielen Nodes zur selben Zeit zu versenden.
% Die Priorisierung verschiedenster Messages ist anhand des dominanteren Bits an der höher prioren Stelle der jeweiligen Message-ID gegeben.\\
% \\
% Im Anschluss an den Header folgen die Nutzdaten deren Länge durch das Feld Msg-Len im Header angegeben wird und an deren Ende die Checksumme, welche sowohl über den Header- als auch den Nutzdatenteil gebildet wird, folgt.\\
% 
% \section{Uhrensynchronisation}
% Auf den Layer 2 setzt die Uhrensynchronisation / das Messageordering auf.
% 
% \section{Benchmarking und Testing}
% Diese wird mittels Node X mitprotokolliert und am LCD ausgegeben.
% Buttons die sich auf den jeweiligen Nodes befinden (mit diesen verbunden sind) werden dazu verwendet diverse Fehlerszenarien zu aktivieren oder Unschärfen zu verursachen.\\ 




% FIXME merged from presentation
\subsection{Layer 1}
\begin{center}
\begin{itemize}
 \item \begin{large}One wire\end{large}
 \item \begin{large}USART 9N1 configuration\end{large}
\end{itemize}
\vspace{1cm}
\begin{bytefield}{11}
 \bitheader{0-1,9-10}\\
 \bitbox{1}{S} \bitbox{9}{Datenbits} \bitbox{1}{S}\\
\end{bytefield}
\end{center} 



\subsection{Layer 2}
\begin{center}
\begin{itemize}
  \item \begin{large}Bus tailored to our needs\end{large}
  \item \begin{large}Bus arbitration\end{large}
  \item \begin{large}CSMA/CA\end{large}
  \item \begin{large}Non-starvation handling\end{large}
  \item \begin{large}Re/integration handling\end{large}
\end{itemize}
\end{center}


\subsection{Layer 2: message format}
FIXME add some bits for Start Of Frame (SOF). SOF has to be unique - so bitstuffing has to be implemented 
for the rest of the message.
\begin{center}
   \begin{bytefield}{24}
     \bitheader{0,3-4,9-10,15-16,23}\\
     \bitbox{4}{Type} \bitbox{6}{Dest ID} \bitbox{6}{Src ID} \bitbox{8}{Len}\\
     \bitbox[lrt]{8}{Data<0>} \bitbox[lrt]{8}{Data<1>} \bitbox[lrt]{8}{..}\\ 
     \skippedwords \\
     \bitbox[lrb]{8}{..}\bitbox[lrb]{8}{Data<Len-2>}\bitbox[lrb]{8}{Data<Len-1>}\\
     \bitbox[lrb]{8}{CRC<0>}\bitbox{8}{..}\bitbox{8}{CRC<3>}\\
   \end{bytefield}
\end{center}


\subsection{Re/Integration handling}
\begin{center}
\begin{itemize}
 \item \begin{large}Problem: How does an upcoming node detect the beginning of a layer2 message?\end{large}
 \item \begin{large}Solution: ``Sync''-bit in layer1 set at beginning of a layer2-message.\end{large}
 \item \begin{large}Disadvantage: 1 additional bit for every layer1 message but lower cpu usage then bit stuffing and easier to implement.\end{large}
\end{itemize}
\end{center}


\subsection{Starvation handling}
\begin{center}
\begin{itemize}
 \item \begin{large}Problem: Sender stops sending during communication and receiver(s) will wait for data forever.\end{large}
 \item \begin{large}Solution: Receivers enter idle state again if no data has been received within the timeout interval.\end{large}
 \item \begin{large}Disadvantage: HW-Timer has to be used.\end{large}
\end{itemize}
\end{center}